home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1989 / Dec 89 / 0183-Re Failure Handling-Dec89 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.5 KB  |  73 lines  |  [TEXT/GEOL]
  1. Item    0153058                         8-Dec-89        08:23
  2.  
  3. From:   ALGER                           Alger, Jeff,VCA
  4.  
  5. To:     D1950                           CSG, Don Phillips,PRT
  6.  
  7. cc:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Re: Failure Handling
  10.  
  11. Jo-Anne,
  12.  
  13. Your question is, "what is the best way to implement failure handling...."  The
  14. code fragment you presented will work just fine and may be appropriate for some
  15. cases, not so good for others.  Let's deal with some general principles instead
  16. of a specific case.
  17.  
  18. The basic idea of a failure handler is to restore state.  Before a
  19. failure-prone section of code is executed, the program is in state X.  If a
  20. failure occurs between a CatchFailures and a Success, the failure handler is
  21. responsible for restoring the program to state X, then taking action
  22. appropriate when it is known that the succeeding block of code will not work.
  23. In pseudo-code,
  24.  
  25. IF SomeCode will work if tried THEN
  26.    SomeCcode
  27. ELSE
  28.    do something else
  29.  
  30. Typically, you cannot tell in advance whether the code will work properly, so
  31. the failure handler "backs up" to the state of the program at the IF, then
  32. resumes with the ELSE.
  33.  
  34. To support this activity, CatchFailures stores the machine registers on its
  35. internal stack and Fail restores them.  Thus, local variables, the stack
  36. pointer, etc., are all restored for you automatically.  All you have to do is
  37. undo any intermediate damage done between the CatchFailures and the Fail, such
  38. as freeing newly allocated objects.
  39.  
  40. The normal behavior of the failure trapping mechanism when a failure occurs is
  41. to restore the state of the top (most recent) failure handler, call it, then
  42. repeat with the next failure handler on the stack, etc.  If the stack is
  43. exhausted, the program aborts.  If you want to write a failure handler which
  44. does not keep percolating upward, do something like
  45.  
  46. PROCEDURE TObjectX.DoSomething;
  47.    VAR
  48.       fi: FailInfo;
  49.    PROCEDURE LocalFailureHandler (error: OSErr; message: LONGINT);
  50.    BEGIN
  51.       GOTO 1234;
  52.    END;
  53. BEGIN
  54.    CatchFailures (fi, LocalFailureHandler);
  55.    { do something which can fail }
  56.    Success (fi);
  57.  
  58.    1234:
  59.    { do something else }
  60. END;
  61.  
  62. MacApp is friendly enough to do this by default by pushing a default failure
  63. handler which does a GOTO to resume the idle loop.  Unless you take steps to
  64. exit the loop prematurely, your failure handlers will be called in the reverse
  65. order in which they were pushed using CatchFailures until this default handler
  66. is reached.
  67.  
  68. I hope this helps.
  69.  
  70. Jeff Alger
  71. KPMG Peat Marwick
  72.  
  73.